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ABSTRACT 

This paper examines some of the potential challenges 
associated with enabling a seamless web experience 
on underpowered mobile devices such as Google Glass 
from the perspective of web content providers, device, 
and the network. We conducted experiments to study the 
impact of webpage complexity, individual web compo¬ 
nents and different application layer protocols while ac¬ 
cessing webpages on the performance of Glass browser, 
by measuring webpage load time, temperature variation 
and power consumption and compare it to a smartphone. 
Our findings suggest that (a) performance of Glass com¬ 
pared to a smartphone in terms of power consump¬ 
tion and webpage load time deteriorates with increas¬ 
ing webpage complexity (b) execution time for popu¬ 
lar JavaScript benchmarks is about 3-8 times higher on 
Glass compared to a smartphone, (c) WebP is more en¬ 
ergy efficient image format than JPEG and PNG, and 
fd) seven out of 50 websites studied are optimized for 
content delivery to Glass. 
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1. INTRODUCTION 

Over the past two decades, the web has changed 
significantly, evolving from basic webpages with hy¬ 
perlinks to a substantially more complex ecosystem 
with dynamic webpages and dynamic content de¬ 
livery models. While the web ecosystem has be¬ 
come complex, the devices accessing the web are 
becoming smaller, moving from desktop to tablets 
to smartphone and now wearables. The trade-off 
between ever increasing web complexity and grad¬ 


ual miniaturization of devices having limited pro¬ 
cessing capabilities and power posits an interesting 
question: How does the current web ecosystem im¬ 
pact the performance of underpowered devices? In 
this paper, we address this question by considering 
a popular smartglass: Google Glass. 

The main focus of this paper is (a) to quantify 
the web browser performance on Glass and compare 
it to a smartphone browser, (b) to understand the 
factors potentially responsible for the performance 
differences between the two devices, and (c) pro¬ 
vide insights as to how content providers can offer a 
better user quality of experience on underpowered 
devices. A profiler is developed for both Glass and 
smartphone to monitor four performance metrics: 
power consumption, temperature variation, down¬ 
loaded bytes and webpage load time while loading 
the webpages using WiFi over a series of experi¬ 
ments. The initial experiment consists of accessing 
50 popular websites under various categories from 
Alexa Top 500. The next set of experiments deals 
with loading synthetic webpages, executing popu¬ 
lar JavaScript benchmarks and loading different im¬ 
age formats. The final experiment is to access the 
websites measured in the initial experiment using 
HTTPS. Additionally, we analyzed tcpdumps and 
examined the web objects served by 50 websites to 
find if they provide different web experience to Glass 
and smartphone. 

Based on our experiments, the important results 
are: 

• The performance of Glass compared to a 
smartphone in terms of total power consump¬ 
tion and webpage load time deteriorates with 
increasing number of web objects, number of 
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servers accessed and number of JavaScripts on 
a webpage. The webpage load time for the 
landing page of popular websites is very high 
(2x on average) on Glass compared to a smart¬ 
phone. However, 2x higher webpage load time 
only results in 1.2x (on average) higher total 
power consumption on Glass due to a lower 
rate of power consumption than a smartphone. 

• JavaScript is the most resource intensive web 
component. The Glass browser is about 3-8 
times slower than the Chrome browser on a 
Nexus 5 smartphone, while executing the same 
JavaScript benchmarks. The execution time 
for 3rd party analytics and ad scripts on Glass 
is about 2x that of smartphone. 

• WebP image format is more energy efficient 
than JPEG and PNG on Glass. For example, 
using WebP instead of JPEG on m.wikihow. 
com results in 45 % savings in power consump¬ 
tion and 50 % lower webpage load time. 

• The cost of accessing a website using HTTPS 
on Glass when compared to a smartphone in¬ 
creases with increasing number of web objects, 
webpage size and the number of servers ac¬ 
cessed through the webpage. For instance, 
Glass power consumption is 27 % lower than 
smartphone for webpages with less than 64 
web objects. However, the power consump¬ 
tion on Glass becomes 17 % higher to that 
of smartphone when loading webpages having 
more than 64 web objects. 

• Seven out of the 50 studied websites are opti¬ 
mized for content delivery to Glass. For exam¬ 
ple, m.espn.go.com optimize by serving im¬ 
ages according to the Glass screen dimensions. 

The rest of the paper is organised as follows. Sec¬ 
tion 2 discusses related work. Section 3 explains ex¬ 
perimental setup. Performance results are discussed 
in Section 4. Section 5 concludes the paper. 

2. RELATED WORK 

Prior works have investigated the performance of 
web browser on desktop and smartphones from dif¬ 
ferent perspectives such as caching, protocols and 
webpage content mm, webpage complexity [4] and 


energy [5]. In contrast, our major focus is, (a) to 
find out the web browsing performance issues on an 
underpowered device such as Glass and, (b) how to¬ 
day’s webpage complexity and design contribute to 
such issues. 

Xiao et al. 0 developed WProf to profile web 
browser activities on a desktop to measure the web¬ 
page load time accurately. Their study on 350 web¬ 
pages concluded that synchronous JavaScript con¬ 
tributes significantly to the webpage load time and 
SPDY [7j reduces webpage load time only for low 
bandwidth networks. SPDY is a network protocol 
developed at Google to achieve smaller web page 
load latencies. Michael et al. [4] demonstrated the 
performance impact of increasing webpage complex¬ 
ity on webpage load time by characterizing 2000 
websites landing pages on a desktop browser. Sim¬ 
ilar to earlier observations by Michael et al. j3], 
we found out that the number of requested web ob¬ 
jects, number of servers and number of javascripts 
have the highest impact on the webpage load time. 
Our work differentiates from the aforementioned 
two studies by studying web browser performance 
not only in terms of webpage loading time but also 
power consumption and temperature variation on 
mobile devices. 

Thiagarajan et al. [5] created a system to exclu¬ 
sively measure smartphone browser energy for pop¬ 
ular websites based on their content. In contrast, 
our work measures browser performance along mul¬ 
tiple metrics taking into account webpage complex¬ 
ity, webpage content and different application pro¬ 
tocols. Qian et al. [5] suggested factors including 
protocol overhead, webpage content and caching af¬ 
fect resource utilization for mobile web browsing. 
We measured the impact of similar factors on Glass 
and smartphone browsers. 

3. EXPERIMENTAL SETUP 

The experimental setup consists of a Google 
Glass, a Nexus 5 smartphone (Chrome browser 
42.0) and a laptop. We also repeated the same set 
of experiments with Sasmung Galaxy S4 and Nexus 
5X, and observed performance difference trends be¬ 
tween Glass and the two smartphones to be similar 
to Nexus 5. For brevity, we only report results for 
Nexus 5. The laptop runs Mac OS X, has 8 GB of 
RAM and 2.6 GHz processor. Our experiments can 
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be broadly divided into two categories: accessing 
real webpages on the Internet from Glass and smart¬ 
phone, and accessing synthetic webpages hosted on 
a local Apache web server running on a laptop from 
Glass using WiFi. The synthetic webpages are cre¬ 
ated for two scenarios: (a) Hosting landing pages 
of websites that are considered for studying the im¬ 
pact of various web components on browser, and 
(b) Image format comparison experiments. Host¬ 
ing webpages on a local server provides a way to 
control webpage content according to experimental 
needs. More details are presented in Section 4.2.1 
and 4.2.3. Overall goals of our experiments is to 
study the impact of webpage complexity, individ¬ 
ual web components and accessing webpages using 
different application layer protocols on the perfor¬ 
mance of Glass and smartphone browser and com¬ 
pare them. 

We created an application for both Glass and 
smartphone, which invokes the browser with the 
website url to be accessed as an input. Browser 
cache is emptied before each experiment. We also 
developed a profiler app for both the devices. Pro¬ 
filer runs in the background and collects the fol¬ 
lowing performance metrics every second and writes 
them to a file with timing information for later anal¬ 
ysis: 

• Power consumption is obtained by multiplying 
the current and voltage readings obtained from 
current-now and voltage-now files present at 
/sys/class/powersupply/battery. 

• Glass device temperature is obtained by read¬ 
ing /sys/devices/platform/notle-pcbsensor. 0/ 
temperature file. 

• Downloaded bytes is obtained by using getU- 
idRxBytes function from Android framework 
0 . 

• Webpage load time is measured from the time 
of first DNS request (start time) to the time 
when browser receives the last web object (end 
time). The profiler extracts the start and end 
time from the browser logs. 

All the experiments are repeated six times and 
the results reported are averages unless stated oth¬ 
erwise. Each experiment is first performed on Glass 


and then on smartphone. The battery of the de¬ 
vices is fully charged. Glass is always allowed to 
cool down to around 37 °C before commencing ex¬ 
perimentation. While taking measurements, only 
profiler , app to invoke the browser and the browser 
are running on the devices. 

4. RESULTS 

4.1 Browser Performance for Popular 
Websites 

Our first experiment studies how the complex¬ 
ity of webpages affects the performance of Glass in 
comparison to a smartphone. The top categories of 
websites being accessed from Glass are media, enter¬ 
tainment, sports, news, informational and technol¬ 
ogy ID- We picked 50 popular websites (mentioned 
in Appendix) from Alexa Top 500 under the afore¬ 
mentioned categories. We found seven websites to 
be optimized for content delivery on Glass and are 
hence discussed separately in Section 4.4. 

To compare the performance between Glass and 
a smartphone, we choose to represent relative per¬ 
formance (Glass/Smartphone) ratio in the results 
for each metric: total power consumption and web¬ 
page load time. Temperature variation metric is 
only shown for Glass. A ratio of less than one means 
Glass fares better than smartphone and vice versa. 
To understand the causes for performance differ¬ 
ences between Glass and smartphone, we first did 
a correlation analysis for three aforementioned per¬ 
formance metrics against webpage complexity fac¬ 
tors: number of web objects, number of servers con¬ 
tacted, total bytes, number of JavaScripts, number 
of CSS and number of images. Next, websites are 
binned based on the common highest correlated fac¬ 
tor amongst all the factors to depict the relative 
performance. The results are shown in Figure [l] 

Figure [Ta| shows that across all three performance 
metrics, the three most correlated web complexity 
factors are the total number of web objects, the 
number of Javascripts within these objects, and the 
number of servers contacted while loading the web¬ 
page with a very high correlation coefficient (0.6- 
0.8). As Glass is computationally less powerful than 
a smartphone, the performance gap increases with 
every connection a browser has to create to fetch a 
web component, which is determined by the num- 
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Figure 1: Comparison of Web Browsing Performance 


ber of web objects and the number of servers to be 
accessed. Amongst the web components, the high¬ 
est impact is caused by JavaScripts, shown in the 
next section. 

Figure |Tb]|ld| confirms the strong correlation be¬ 
tween three performance metrics and the number of 
web objects. On the x-axis, the first item is the in¬ 
terval representing the number of web objects. The 
second item refers to the number of websites in the 
interval. The total power consumption and web¬ 
page load time for Glass in comparison to a smart¬ 
phone deteriorates with the increasing number of 
web objects. The temperature rise on Glass also 
shows the same observation. As, Glass and Nexus 
5 are using same WiFi technology and access point, 
we suspect the processor to be mainly responsi¬ 
ble for the deterioration. Glass processor capabil¬ 
ity (1.2 GHz) is almost half that of Nexus 5 (2.25 


GHz), which results in slower processing of web con¬ 
tent and hence prolong webpage load time. Our re¬ 
sults confirms the webpage load time for Glass to 
be roughly two times that of Nexus 5. The cost 
of accessing websites can be reduced on Glass by 
designing webpages having a small number of web 
objects (fewer JavaScripts) being fetched from fewer 
servers. 

4.2 Browser Performance for Web Com¬ 
ponents 

To understand how the modern website design af¬ 
fects the Glass browser performance, we performed 
three different experiments. First, we measured 
the webpage load time and power consumption for 
three key elements: CSS, JavaScript and Images for 
the synthetic landing webpage of websites on Glass. 
Second, we measure the execution time of popular 
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(a) Percent of total power consumption by web 
components. “Others” includes text and fonts. 



(b) Contribution to Webpage Load Time by 
JavaScripts compared to all other web components 
(CSS+Images+Text+Fonts) 


Figure 2: Glass Browser Performance for Synthetic Landing Webpage of Websites 


JavaScript benchmarks, analytics and ad scripts on 
Glass and smartphone. Third, we study the power 
consumption of JPEG, PNG and WebP image for¬ 
mats on Glass. 

4.2.1 Synthetic WebPages: Breakdown Analysis 
by Web Components 

To conduct our experiments, we created a copy 
of the website landing pages on a local Apache web 
server (version 2.2.29). The local HTML copy al¬ 
lows us to systematically add or remove web com¬ 
ponents. The local server only contains a copy of 
website landing HTML page. All the web objects 
embedded inside the webpage are still served by the 
original servers. We chose to do so because mod¬ 
ern websites are complex and have dynamic con¬ 
tent, which makes it impractical to store each and 
every web object embedded inside the landing page 
on the local server. 

The energy consumed by each web component 
is estimated by comparing the energy consumption 
used for loading the entire webpage to the energy 
consumption needed for loading the webpage with 
a specific type of web component removed by fil¬ 
tering it out from the HTML code. We followed 
two criteria while selecting websites for these exper¬ 
iments: (a) the website landing HTML page should 


not make any web object request to the local server, 
(b) images present on the landing page should not 
be embedded inside a CSS or JavaScript. These 
two criteria prevents the skewness in measurements 
and ensures that local server only gets a request for 
the landing HTML webpage. 12 out of 50 websites 
passed both the criteria. 

The results are shown in Figure [2] In general, 
JavaScript is the most power hungry web compo¬ 
nent across the websites as shown in Figure |2a| 
JavaScript consumes more than 40 % of the total 
power on 10 of the 12 websites. JavaScript is also 
the highest contributor to the webpage load time as 
shown in Figure [2b| The presence of JavaScript con¬ 
tent on today’s websites is very recurrent. A recent 
study [3] indicates that 33 % of the total JavaScript 
on mobile webpages remain unused on a smart¬ 
phone browser. Analytics, Ads and tracking-related 
scripts constitute a high number of JavaScripts that 
is not critical to the functional processing of the 
webpage and is of limited utility to a user. Spe¬ 
cial attention should be given to the treatment and 
inclusion of JavaScripts on small devices browsers. 

4.2.2 JavaScript Benchmarks: Comparison 

As JavaScript is the most resource intensive com¬ 
ponent, we compared the JavaScript execution time 
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Figure 3: Time to execute JavaScripts 


across some popular benchmarks: SunSpider ver¬ 
sion 1.02 [12], Dromaeo suite El. and ads and an¬ 
alytics scripts: beacon.js, em.js, analytics.js, ga.js, 
chartbeat.js and gpt.js on Glass and smartphone. 
This provides an estimate as to how slow Glass 
is compared to a smartphone when running the 
same JavaScript. We executed all 26 JavaScripts 
from SunSpider. From Dromaeo suite, Dromaeo 
JavaScript Tests, V8 JavaScript Tests, DOM Core 
Tests and JavaScript Library Tests were executed. 
The results are shown in Figure [3j 

Sunspider benchmark on Glass/Browser is 4x 
slower than Smartphone/Chrome as shown in Fig¬ 
ure I3al The execution time for Dromaeo suite in 
Figure 3b show that the Glass/Browser is about 3- 
8 times slower than Smartphone/Chrome browser, 
while executing the same JavaScript. These re¬ 
sults again highlight the need for today’s websites 
to serve less JavaScript to Glass. The results in 
Figure [3c] shows that the execution time for 3rd 
party scripts on Glass is about 2x that of smart¬ 
phone. Google Publishing Tag (gpt.js) is the most 
time consuming script, which suggests that serving 
ads on Glass can cause significant delay in loading 
webpages. 


4.2.3 Image Formats: Comparison 

We measured the energy consumption of PNG, 
JPEG and WebP image formats on Glass. A JPEG 
image of size 500 KB is chosen for the experi¬ 
ments. This JPEG image is then converted to 
smaller JPEG images and similar PNG and WebP 
images using cwebp [9]. Each image is then embed¬ 


ded in a webpage (that contains only the image) 
on local Apache web server. Figure [4] shows the 
results. The x-axis shows firstly the JPEG image 
size. The two numbers inside the bracket represent 
the corresponding size for PNG and WebP image. 
Study by Josh et al. m showed that depending on 
the quality comparison algorithm, the compression 
ratio between JPG and WebP image files can be 
less than or greater than one while maintaining the 
same quality of image at a particular JPEG level. 
On contrary, we do not exclusively focus on compar¬ 
ing the quality of the image. We choose a particular 
JPEG file size which is converted to a WebP image 
with a quality factor of 75 %. 



Figure 4: Power consumption for image formats on 
Glass 

Our results suggest that the performance gap 
between JPEG and WebP increases with increas¬ 
ing image Hie size because at higher image sizes, 
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Figure 5: Comparison of HTTP vs HTTPS Performance 


WebP gives a better compression ratio that re¬ 
sults in smaller WebP files and hence is the most 
energy efficient format. Hence, webpages can be 
embedded with WebP format instead of PNG or 
JPEG to achieve lower power consumption on un¬ 
der powered devices. As an example, converting all 
JPEG and PNG images to WebP provides savings 
of 20 % in power consumption and 33 % lower web¬ 
page load time for ted.com. Similar conversion on 
m.wikihow. com gives 45 % savings in power and 50 
% lower webpage load time. 

4.3 Cost of HTTPS 

We measured the performance of HTTPS versus 
HTTP on Glass and compare it to a smartphone. 
Webpage load time is measured while accessing a 
website using HTTP and HTTPS and power con¬ 
sumption, temperature variation and downloaded 


bytes is calculated for the duration of the web¬ 
page load time. 18 out of 50 websites sup¬ 
ported both HTTP and HTTPS. However, we 
could only compare results for 13 websites because 
two website loads less content on HTTPS than 
HTTP and three websites have been optimized for 
Glass. Similar to Section 4.1, relative performance 
(Glass/Smartphone) ratio is used to represent the 
results. 

We did a correlation analysis similar to Section 
4.1 and then binned websites based on the common 
highest correlated factor to depict the relative per¬ 
formance. The result is shown in Figure [5j Figure 


5a shows that the number of web objects as the com¬ 


mon factor among the top three factors for the three 
performance metrics: relative total power consump¬ 
tion, relative webpage load time, and temperature 
variation on Glass. 
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Figure [5b][5d] shows that the relative performance 
of Glass compared to a smartphone deteriorates 
with increasing number of web objects on a web¬ 
page. For the webpages with smaller number of 
web objects (<64), Glass webpage load time is 27 
% higher than smartphone. However, Glass power 
consumption is 27 % lower than smartphone due 
to the lower rate of power consumption. With in¬ 
creased number of web objects (>64), we see 69 % 
higher webpage load time and 17 % higher power 
consumption on Glass compared to a smartphone. 
The cost of HTTPS can be attributed to the extra 
time to maintain and create HTTPS connections 
which increases with increasing number of web ob¬ 
jects and the number of servers to contact. More 
time also leads to more power consumption and 
higher temperature on Glass. 

4.4 Optimized Websites 

Seven websites: rn.espn.go.com, m.Wikipedia, 
com, rn.wikihow.com, goodreads.com, telegraph. 
co.uk, rn.youtube.com, and mobile.bloomberg. 
com provide tailored content to Glass. The general 
methodology employed by these tailored websites is 
to deliver less content to Glass than smartphone. 
Next, we discuss specific features discovered by an¬ 
alyzing tcpdumps. 

rn.espn.go.com and rn.wikipedia.com optimize 
by delivering the images to Glass browser accord¬ 
ing to the device screen dimensions which results in 
50 % and 70 % reduction in image content down¬ 
load respectively. Considering the number of images 
on m. espn. go . com (35) and m. Wikipedia, com (26), 
the reduction is considerable. Glass screen dimen¬ 
sion (427*240) is smaller than Nexus 5 (640*360). 
Upon receiving request from any device, the server 
identifies the device type and its display properties, 
which is then used to send appropriate sized con¬ 
tent to the device. Accessing m. Wikipedia. com and 
rn.wikihow.com on Glass fetches less php scripts 
than smartphone, resulting in savings of (450 kB). 
goodreads. com does not fetch a particular CSS on 
Glass which is required only for smartphone and 
hence saves 700 kB of traffic, telegraph.co.uk 
optimize by not showing ads on Glass and thereby 
avoiding 1 MB of ad related scripts. 

rn.youtube.com and mobile.bloomberg.com 
have a different version of website for Glass and 


smartphone. Note that different version mean ac¬ 
cessing m.youtube.com or mobile.bloomberg.com 
fetches a different HTML file for the landing page. 
rn.youtube.com serves 50 % (700 kB) lesser and 
mobile.bloomberg.com serves 60 % (1.5 MB) 
lesser content to Glass than smartphone version of 
the website. 

5. CONCLUSION 

In general, the browsing performance on Glass 
is worse than a smartphone primarily because the 
same content is being delivered to Glass and smart¬ 
phone regardless of the device type. Glass is an 
underpowered mobile device with smaller process¬ 
ing power and smaller battery than smartphones. 
The following suggestions might be beneficial for 
efficient browsing on underpowered devices: 

• Reducing web content: As JavaScripts sig¬ 
nificantly impede the performance of Glass 
browser, their quantity and complexity can be 
reduced. Serving less CSS, images, ads and 
keeping in consideration the display capability 
of the requesting device can also reduce the 
content. 

• Efficient image formats: WebP instead of 
JPEG or PNG can be used on webpages to 
save power and lower the webpage load time. 

• Cloud assisted solutions: An underpowered 
device can have a light weight browser us¬ 
ing cloud based acceleration rather than a full 
fledged browser as Glass possess. Another way 
is using a data compression proxy on the cloud, 
thereby reducing network bandwidth, power 
consumption and webpage load time. 

• New protocols: SPDY can be used in place of 
HTTPS to improve browser performance. 
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APPENDIX 


Website 

rn.espn.go.com, rn.wikipedia.com, 
rn.wikihow.com, goodreads.com, 
telegraph.co.uk, rn.youtube.com, 
mobile.bloomberg.com, bing.com, quora.com, 
rn.rediff.com, java.com, i .reditt.com, 
tripadvisor.com, apple.com, rn.yelp.com, 
booking.com, go.com, ted.com. rn.9gag.com, 
rn.aol.com, adobe.com, deviantart.com, 
gizmodo.com, skype.com, rn.gsmarena.com 
nhl.com, dell.com, taboola.com, rn.goal.com, 
m.bleacherreport.com, m.indiatimes.com, 
diply.com, rn.huffpost.com, microsoft.com, 
rn.foxnews.com, rn.bbc.com, rn.ndtv.com, 
theladbible.com, techcrunch.com, 
businessinsider.com, rn.imdb.com, rn.mlb.com, 
engadget.com, answers.com, photobucket.com, 
theguardian.com, mweb.cbssports.com, 
lenovo.com, dailymail.com, m.espncricinfo.com 

Table 1: Websites Used In Measurements 
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